Mobile Core Network Node Redundancy

ABSTRACT

Apparatus configured to operate within a communication network as a pool proxy, routing signalling traffic between a node of a first network and one of a set of pooled nodes within a second network. The apparatus is further configured to operate in one of an active state and a passive state towards the first network node and, when in said active state to send a heartbeat signal to at least one of said pooled nodes for relaying to a peer pool proxy and, when in said passive state, to receive a heartbeat signal from a peer pool proxy relayed via at least one of said pooled nodes. In the event that no heartbeat signal is received when in the passive state, the apparatus is configured to activate itself as pool proxy towards the first network node.

TECHNICAL FIELD

The present invention relates to the provision within a network for node redundancy using a node pool and a pool sharing proxy. The invention is applicable in particular, though not necessarily, to the effective provision of a pool of Mobile Switching Centre nodes within the circuit switched core of a mobile telecommunication system.

BACKGROUND

In a conventional second generation mobile communication network, each geographical cell of the network is served by a Base Station Transceiver (BST) which provides the network side of the air interface. A set of BSTs are physically connected to a Base Station Controller (BSC) which is in charge of the allocation of radio resources to subscribers. Each BSC is in turn physically connected to a Mobile Switching Center which is responsible for the routing of incoming and outgoing calls to the mobile network and is responsible, in particular, for handling the mobility of subscriber devices. In the case of a 3G network, so-called Node B's are broadly equivalent to the BSTs of the 2G network, whilst the Radio Network Controller (RNC) takes the place of the BSCs. Both 2G and 3G networks may comprise packet-switched core networks in addition to the circuit-switched core network. In the packet-switched network architecture, the MSC is replaced by the Serving GPRS Support Node (SGSN).

Traditionally, vertically integrated networks have been built to deliver single services such as telephony or data access. FIG. 1 illustrates this vertically integrated architecture in the case of a 2G network. However, in order to increase the “modularity” of network components and therefore reduce network construction and operating costs, a solution sometimes known as the Mobile Softswitch Solution (MSS) architecture has been introduced. This architecture is described in an Internet published whitepaper titled “Efficient Softswitching”, Ericsson A B, August 2006, which can be found at: http://www.ericsson.com/technology/whitepapers/8107_efficient_softswitching_a.pdf. Softswitching in combination with IP technology allows for a layered architecture approach according to which service execution, control and connectivity can be horizontally integrated across multiple access networks. Softswitches separate the call control and switching functions into different nodes, consequently separating control and connectivity layers.

As a particular example, the conventional MSC is split in the layered softswitch architecture into an MSC Server (MSC-S) which handles the control plane signalling and a Mobile Media Gateway (M-MGW) which handles user plane traffic. A Gateway Control Protocol (GCP) is used between the MSC-S and the M-MGW in order to allow the MSC to control user plane bearers. All GCP signalling messages are transported between the M-MGW and the MSC-S using a long-lived Stream Control Transmission Protocol (SCTP) association established between the two entities. Although the M-MGW does not make use of the control plane signalling as such, this signalling is relayed by the M-MGW en route from the BSC/RNC to the MSC-S. More particularly, it is possible to transport this signalling over a second SCTP association established between the M-MGW and the MSC-S.

In today's advanced MSS networks, server pooling is the standardised concept to achieve geographical redundancy in the networks. This avoids inter alia the failure of a single server from resulting in a failure of the network to provide services to subscribers. A generalised MSS server pooling architecture is illustrated in FIG. 2. In the case of an MSC-S pool, it will be appreciated that if one MSC-S fails, BSCs/RNCs currently allocated to that MSC-S can be reallocated. In a pooled architecture, an MSC Pool Proxy can be introduced between the BSC/RNC and a pool of MSC-S in order to support BSCs/RNCs that do not support MSC-S pooling. This Pool Proxy acts as a single point of contact for BSCs/RNCs to the MSC-S pool. In more general terms a pool proxy is used to connect network nodes to pool nodes. Such pool nodes can be pool servers. Whilst the MSC Pool Proxy can be a standalone node, it is preferable to integrate this functionality into the M-MGW in order to save on operating costs.

The pooled approach to the provision of network nodes provides security against failure of an individual pooled node. However, a pool proxy itself constitutes an architectural element that is a critical point of failure. It is therefore desirable to introduce pool proxy redundancy into the architecture, for example as illustrated in FIG. 3 for the case of an MSC-S pool. One approach to this involves configuring each BSC/RNC to be able to independently address two (or more) pool proxies, where in this example the pool proxies are located at respective M-MGWs.

A BSC or RNC may be unaware of the presence of the pool proxy, with the BSC or RNC merely addressing the proxy using the Signalling Point Code (SPC) as if the proxy were a regular MSC. Such a BSC or RNC cannot separately address a plurality of pool proxies (or MSCs as the BSCs or RNCs see them).

A problem to be addressed therefore is how to introduce pool proxy redundancy into a network without giving rise to conflicting signalling on the interface between the pool proxies and the BSCs/RNCs or other network nodes.

SUMMARY

It is an object of the present invention to overcome or at least mitigate the problem noted above. This object is achieved by sending a heartbeat signal from an active pool proxy towards a passive pool proxy via the pooled nodes.

According to a first aspect of the present invention there is provided apparatus configured to operate within a communication network as a pool proxy, routing signalling traffic between a first node and one of a set of pooled second nodes, the apparatus being further configured to operate in one of an active state and a passive state towards the first node and, when in said active state to send a heartbeat signal to at least one of said pooled second nodes for relaying to a peer pool proxy and, when in said passive state, to receive a heartbeat signal from a peer pool proxy relayed via at least one of said pooled second nodes, wherein, in the event that no heartbeat signal is received or the received signal does not satisfy some minimum criterion, when in the passive state, the apparatus is configured to activate itself as pool proxy towards the first network node.

Embodiments of the invention allow a downstream node to be coupled to multiple pool proxies whilst at the same time allowing only one of the pool proxies to be visible at any given time. Thus, signalling conflicts can be avoided.

According to a second aspect of the present invention there is provided apparatus configured to operate within a communications network as one of a set of pooled second nodes serving one or more first nodes, the apparatus being further configured to receive a heartbeat signal from an active pool proxy and to relay the heartbeat signal to a passive pool proxy.

According to a third aspect of the present invention there is provided a method of providing redundancy within a communication network comprising two or more pool proxies routing signalling traffic between a first node and one of a set of pooled second nodes, the method comprising maintaining one of the pool proxies in an active state towards said first node and the other pool proxy in a passive state, sending a heartbeat signal (105) from the active pool proxy to the passive pool proxy via one or more of said pooled second nodes, and, in the event that the heartbeat signal is not received at the passive proxy, activating (104) that proxy towards the first node.

According to a fourth aspect of the present invention there is provided a method of providing redundancy within a communication network comprising two or more pool proxies routing signalling traffic between a first node and one of a set of pooled second nodes, the method comprising, at one of said pool proxies, maintaining (103) the proxy in a passive state towards said first node, receiving (101,102) a heartbeat signal from one or more of said pooled second nodes and, in the event that the heartbeat signal is not received, activating (104) the pool proxy towards said first node.

According to a fifth aspect of the present invention there is provided a method of providing redundancy within a communication network comprising two or more pool proxies routing signalling traffic between a first node and one of a set of pooled second nodes, the method comprising, at one of said pooled second nodes, receiving (202) a heartbeat signal from one of said pool proxies and relaying (203) the heartbeat signal to another of the pool proxies.

According to a sixth aspect of the present invention there is provided a computer program comprising computer program code means adapted to perform the method of the above aspects of the invention, when said program is run on a computer.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates schematically a simplified radio access network and core network architecture for a 2G/3G network;

FIG. 2 illustrates schematically a generic server pool architecture in which a pool proxy is used to connect downstream network nodes to pool servers;

FIG. 3 illustrates schematically a Mobile Softswitch Solution architecture implemented within a 2G/3G network and in which pool proxies are co-located with M-MGWs;

FIG. 4 illustrates signalling associated with controlling a passive and an active MSC Pool Proxy of an MSS architecture;

FIG. 5 illustrates schematically an MSC Pool Proxy according to an embodiment of the present invention;

FIG. 6 illustrates schematically an MSC server according to an embodiment of the present invention;

FIG. 7 is a flow diagram illustrating the operation of the MSC Pool Proxy of FIG. 5; and

FIG. 8 is a flow diagram illustrating the operation of the MSC server of FIG. 6.

DETAILED DESCRIPTION

Referring to the Mobile Softswitch Solution (MSS) 2G architecture of FIG. 3 according to which each BSC (or RNC according to 3G) is connected to two Mobile Media Gateways (M-MGWs), an embodiment of the present invention will now be described. In this embodiment, the MSC Pool Proxies are implemented in M-MGWs. Furthermore, a BSC of this embodiment is unaware that it is connected to two M-MGWs/MSC Pool Proxies, as the links to these belong to the same link set. The BSC is configured with a single Signalling Point Code (SPC) which it uses over the GSM A interface (BSSAP protocol) to communicate with an MSC. As such, the BSC can be a legacy (e.g. GSM) BSC.

The current SS7 rules and standards only allow a BSC to address a single SPC. If the BSC is connected to two or more network nodes having the same SPC, the handling of Signalling Network Management (SNM) messages becomes impossible. A possible solution to this problem involves configuring two pool proxies with the same SPC, but ensuring that only one of these is active at any one time. Only in the event that the active pool proxy fails is the passive proxy activated. This is not to say however (in the case of the integrated M-MGW/MSC Pool Proxy) that the M-MGW at which a passive MSC Pool Proxy resides is also in a passive state. Indeed, assuming that the node is functioning normally, the media plane handling operations of the M-MGW will be active. As will be described, a heartbeat signal is sent from the active MSC Pool Proxy to the passive MSC Pool Proxy in order to control the state of the latter.

The active proxy could transmit the heartbeat via a direct link (such direct links are not currently implemented) to the passive proxy. As long as the heartbeat is received by the passive proxy, that proxy remains passive. Only if the heartbeat is not received does the passive proxy activate itself. A problem with this approach, i.e. sending a heartbeat via a direct link between the proxies, is that if the passive proxy does not receive a heartbeat, this could be due to a failure of the active proxy or because the direct link has gone down. In the latter case, the active proxy is still functioning and the activation of the passive proxy will result in the collision of messages and a possible service failure.

A solution to this problem will now be described, considering by way of example the MSS architecture of FIG. 3. It will be appreciated however that the invention can be applied to any pooled node architecture requiring pool proxy redundancy.

Within both the active and the passive MSC Pool Proxies, TDM signalling links are established with the BSC for the purpose of transporting BSSAP signalling, e.g. relating to mobility and connection management. These links are shown in FIG. 3. However, only the link to the active MSC Pool proxy is active. Stream Control Transmission Protocol (SCTP) is used in order to ensure the reliable transport of messages between each MSC Pool Proxy and the MSC-S pool. More particularly, one SCTP association is established between each Pool Proxy and each MSC-S. Again, these SCTP associations are fully active only for the active MSC Pool Proxy, whilst they are inactive in the case of the passive MSC Pool Proxy. Thus, no conflicts arise on the A interface. In addition to the BSSAP related SCTP associations, SCTP associations are established between each M-MGW and each of the pool MSC-Ss for the purpose of carrying the Gateway Control Protocol (GCP) signalling. These GCP related associations are active, even for the M-MGW in which a passive MSC Pool Proxy resides.

In order to allow the passive MSC Pool Proxy to be able to identify an effective failure of the active MSC Pool Proxy, due either to a failure of the active MSC Pool Proxy or a failure of the BSSAP related links between the active MSC Pool Proxy and the MSCs (which has the same result as a Pool Proxy failure), heartbeat signals are sent from the active MSC Pool Proxy to the passive MSC Pool Proxy via the MSC-Ss. In more general terms, the servers of the server pool relay the heartbeat signals from the active pool proxy to the passive pool proxy. Preferably, the heartbeat signals are transported between the active MSC Pool Proxy and the MSC-Ss over the BSSAP related SCTP associations, although as an alternative the GCP related SCTP associations may be used. Between the MSC-Ss and the passive MSC Pool Proxy, the heartbeat signals are transported over the GCP related SCTP associations using separately assigned SPCs for the MSC Pool proxies (or the same SPC used for the GCP signalling towards the M-MGW where the passive MSC Pool Proxy is located).

The heartbeat signal is typically a periodically transmitted message which conforms to some appropriate protocol. In one example, this might be a “ping” type message, i.e. not containing a payload. In another example, the heartbeat signal may consist of messages each containing the identity of the sending pool proxy and/or the identity of the relaying MSC-S and/or a timestamp (for security purposes). Rather than being set periodically, the messages making up the heartbeat signal may be “event” triggered. In this case, the passive MSC Pool Proxy may define a window within which it expects to receive a heartbeat message, resetting the timer each time a heartbeat message is received.

In order to guarantee that the heartbeat signals will be received by the passive MSC Pool Proxy even if only a single MSC-S has active connections with both the active and passive MSC Pool Proxies, the active MSC Pool Proxy sends the heartbeat signals on a round robin basis to the MSC-Ss. Other appropriate selection mechanisms may alternatively be used. For example, the Pool Proxy may select MSC-Ss at random, or use only a subset of all available MSC-Ss.

Following installation of the MSS architecture described here, one of the MSC Pool Proxies (PP A) is defined as active and the other (PP B) as passive. The passive proxy is configured to listen for a transmitted heartbeat signal and to remain passive as long as the heartbeat signal is received within some predefined minimum frequency and/or pattern. For example, the passive proxy may remain passive as long as heartbeat messages are received from at least one of the MSC-Ss and with some minimum frequency. However, if the expected heartbeat signal is not received, the passive MSC Pool Proxy shall activate itself as this will imply that either the active MSC Pool Proxy has failed or all of its links to the MSC-S pool have gone down (nb. the passive Pool Proxy is able to separately determine if its links to the MSC-Ss have failed). The activated MSC Pool Proxy now activates the BSSAP related SCTP associations towards the MSC-S pool, and the signalling links towards the BSC. It also begins sending its own heartbeat signals towards the “failed” MSC Pool Proxy via the MSC-S pool. As such, if the failed MSC Pool Proxy (or its links to the MSC-S pool) subsequently recovers, it will not reactivate itself.

Signalling associated with a Pool Proxy failure is illustrated in FIG. 4, where in this simplified example the MSC-S pool consists of a pair of MSC-Ss, namely MSC A and MSC B. Initially, a first Pool Proxy (PP A) is active whilst a second Pool Proxy (PP B) is passive. PP A sends heartbeat messages towards MSC A and MSC B in turn, which relay the messages to PP B. PP B remains passive so long as the messages are received. Assume now that the SCTP association between PP A and MSC A is lost, but that the association between PP A and MSC B remains alive. In this case, heartbeat messages continue to be relayed to PP B via MSC B, and PP B remains passive. In the event that the SCTP association between PP A and MSC B is also lost, and assuming that PP A remains online (i.e. it is only the SCTP associations that are lost), as illustrated in the Figure PP A will deactivate its links to the BCS and its upstream SCTP associations. PP B notices now that no heartbeat messages are being received by it (timeout), and therefore switches to the active state. It activates its links to the BSC, activates the upstream SCTP associations to MSC A and MSC B, and starts sending heartbeat messages towards PP A.

In the event that a passive MSC Pool Proxy is restarted for any reason, or looses connectivity (including the GCP connections), it will by default remain in the passive state when it recovers, unless of course it does not receive the heartbeat signal (according to the predefined threshold policy), indicating a failure of the active proxy or associated GCP links, in which case it is activated.

The relaying of heartbeat messages in the MSC-Ss can be done either via M3UA Relay or SCCP Relay. In the case of M3UA Relay, heartbeat messages are relayed using SPCs, while in the case of SCCP Relay Sub-system Numbers and Global Titles may also be used for routing.

FIG. 5 illustrates schematically the structure of an MSC Pool Proxy 1 for use within the network architecture described above. A controller 2 is arranged in the passive operating state to receive heartbeat signals from pool MSC servers. In the event that the controller fails to receive the heartbeat signal, indicating a failure of the active proxy or associated GCP links, it operates a switch 3, turning on a heartbeat signal generator 7 to provide an output heartbeat signal. The controller 2 activates its MSC Pool Proxy, establishing and controlling the necessary links and SCTP associations. FIG. 6 illustrates schematically an MSC-S 4 for use within the described architecture. This comprises a controller 5 for controlling inter alia a switch 6 which receives a heartbeat signal from one of the pool proxies and relays it to the other.

FIGS. 7 and 8 are flow diagrams illustrating a method of operating the Pool Proxy and server node respectively. Considering FIG. 7, this includes the steps of the passive pool proxy listening for heartbeats from the active pool proxy, determining if the signal is correctly received, and maintaining itself in the active or passive state accordingly. Only if it is maintained in the active state is a heartbeat signal generated. Considering FIG. 8, each MSC-S in the server pool is responsible for receiving heartbeat messages from the active pool proxy, and for relaying these to the passive pool proxy. It will be appreciated that the illustrated process may be implemented by way of computer program code running on appropriate hardware platforms.

Whilst the invention has been described above with reference to provision of an MSC-S pool, it will be appreciated that the principles are applicable in general to any scenario where a pool of nodes are served by two or more pool proxies and where proxy redundancy is required. It is only relevant that the heartbeat signal is relayed from an active pool proxy to a passive pool proxy via one or more of the pool nodes.

It will be appreciated by those of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention. For example, whilst the above discussion has been concerned with a 2G architecture, the invention is applicable to a 3G architecture in which the BSCs are replaced by RNCs, and the RANAP protocol is used in place of the BSSAP protocol. The invention is also applicable to a SGSN Pool Proxy network architecture in which BSCs/RNCs are connected to an SGSN pool via two (or more) Pool Proxies. In this case, the heartbeat signals between the Pool Proxies and the SGSNs would be carried via dedicated signalling links. 

1-32. (canceled)
 33. An apparatus configured to operate within a communication network as a pool proxy, routing signaling traffic between a first node and one of a set of pooled second nodes, the apparatus being further configured: to operate in one of an active state and a passive state towards the first node; when in the active state, to send a heartbeat signal to at least one of the pooled second nodes for relaying to a peer pool proxy; and when in the passive state, to receive a heartbeat signal from a peer pool proxy relayed via at least one of the pooled second nodes; wherein, when the apparatus is in the passive state, in the event that no heartbeat signal is received or the received signal does not satisfy some minimum criterion, the apparatus is configured to activate itself as pool proxy towards the first network node.
 34. The apparatus of claim 33, wherein the first node is a node of a first network and the pooled second nodes are nodes of a second network.
 35. The apparatus of claim 34, wherein the first network is a radio access network and the second network is a core network, and wherein the pooled second nodes are pooled server nodes.
 36. The apparatus of claim 35, the apparatus being configured to operate as a Mobile Switching Center pool proxy, routing signaling traffic between a Base Station Controller or a Radio Network Controller and a set of pooled Mobile Switching Center servers.
 37. The apparatus of claim 36, the apparatus being further configured to operate as a Mobile Media Gateway and to communicate with each the Mobile Switching Center as Media Gateway Controller using a Gateway Control Protocol.
 38. The apparatus of claim 37, wherein in the active state, the apparatus is configured to convey the heartbeat signal to the pooled second node(s) via a Stream Control Transmission Protocol association, and wherein the Stream Control Transmission Protocol association is shared with a Gateway Control Protocol interface.
 39. The apparatus of claim 37, wherein in the active state, the apparatus is configured to convey the heartbeat signal to the pooled second node(s) via a Stream Control Transmission Protocol association, and wherein the Stream Control Transmission Protocol association is shared with an interface for carrying control signaling to and from the radio access network node.
 40. The apparatus of claim 37, wherein in the passive state, the apparatus is configured to receive the heartbeat signal from the pooled second node(s) via a Stream Control Transmission Protocol association, the Stream Control Transmission Protocol association being shared with a Gateway Control Protocol interface.
 41. The apparatus of claim 35, the apparatus being configured to operate as a Serving GPRS Support Node pool proxy, routing signaling traffic between a Base Station Controller or a Radio Network Controller and a set of pooled Serving GPRS Support Nodes.
 42. The apparatus of claim 33, wherein in the active state, the apparatus is configured to convey the heartbeat signal to the pooled second node(s) via a Stream Control Transmission Protocol association.
 43. The apparatus of claim 33, wherein in the passive state, the apparatus is configured to receive the heartbeat signal from the pooled second node(s) via a Stream Control Transmission Protocol association.
 44. Apparatus The apparatus of claim 33, the apparatus being configured to send and receive individual heartbeat messages of a heartbeat signal via ones of the pooled second nodes on a round robin basis.
 45. An apparatus configured to operate within a communications network as one of a set of pooled second nodes serving one or more first nodes, the apparatus being further configured to receive a heartbeat signal from an active pool proxy and to relay the heartbeat signal to a passive pool proxy.
 46. The apparatus of claim 45, wherein the pooled second nodes are server nodes of a second network, and wherein the one or more first nodes are nodes of a first network.
 47. The apparatus of claim 46, wherein the second network is a core network and wherein the first network is a radio access network.
 48. The apparatus of claim 46, wherein the apparatus is configured to relay the heartbeat signal via one of a M3UA or SCCP relay.
 49. The apparatus of claim 46, wherein the apparatus is a Mobile Switching Centre.
 50. The apparatus of claim 49, wherein the apparatus is configured to operate as a Media Gateway Controller using a Gateway Control Protocol to control Media Gateways implemented at both the passive and active pool proxies.
 51. The apparatus of claim 50, wherein the apparatus is configured to convey the heartbeat signal to the passive pool proxy via a Stream Control Transmission Protocol association, and wherein the Stream Control Transmission Protocol association is shared with a Gateway Control Protocol interface.
 52. The apparatus of claim 50, wherein the apparatus is configured to receive the heartbeat signal from the active pool proxy via a Stream Control Transmission Protocol association, and wherein the Stream Control Transmission Protocol association is shared with a Gateway Control Protocol interface.
 53. The apparatus of claim 46, wherein the apparatus is configured to convey the heartbeat signal to the passive pool proxy via a Stream Control Transmission Protocol association.
 54. The apparatus of claim 46, wherein the apparatus is configured to receive the heartbeat signal from the active pool proxy via a Stream Control Transmission Protocol association.
 55. Apparatus according to claim 53, the Stream Control Transmission Protocol association being shared with an interface for carrying control signaling to and from the first node.
 56. A method of providing redundancy within a communication network comprising two or more pool proxies routing signaling traffic between a first node and one of a set of pooled second nodes, the method comprising: maintaining one of the pool proxies in an active state towards the first node; maintaining the other pool proxy in a passive state towards the first node; sending a heartbeat signal from the active pool proxy to the passive pool proxy via one or more of the pooled second nodes; and activating the passive proxy towards the first node in the event that the heartbeat signal is not received at the passive proxy.
 57. The method of claim 56, further comprising routing the heartbeat signals via the pooled second nodes on a round robin basis.
 58. The method of claim 56, wherein the first node is a node of a first network and the pooled second nodes are nodes of a second network.
 59. The method of claim 58, wherein the first network is a radio access network; second network is a core network; the pool proxies are Mobile Switching Center pool proxies; the pooled second nodes are Mobile Switching Center servers; and the radio access network node is one of a Base Station Controller and a Radio Network Controller.
 60. The method of claim 59, wherein the pool proxy is implemented at a Media Gateway which communicates with Media Gateway Controller functionality implemented at the Mobile Switching Centre servers.
 61. The method of claim 59, further comprising sending heartbeat signals from the active pool proxy to the pooled second node(s) over a Stream Control Transmission Protocol association shared with an interface for carrying control signaling to and from the radio access network node.
 62. A method of providing redundancy within a communication network comprising two or more pool proxies routing signaling traffic between a first node and one of a set of pooled second nodes, the method comprising, at one of the pool proxies: maintaining the proxy in a passive state towards the first node; receiving a heartbeat signal from one or more of the pooled second nodes; and activating the pool proxy towards the first node in the event that the heartbeat signal is not received.
 63. A method of providing redundancy within a communication network comprising two or more pool proxies routing signaling traffic between a first node and one of a set of pooled second nodes, the method comprising, at one of the pooled second nodes: receiving a heartbeat signal from one of the pool proxies; and relaying the heartbeat signal to another of the pool proxies.
 64. An electronically readable data carrier with stored electronically readable control information configured such that when using the data carrier in a computer system, the control information causes the computer to provide redundancy within a communication network comprising two or more pool proxies routing signaling traffic between a first node and one of a set of pooled second nodes by performing the steps of: maintaining one of the pool proxies in an active state towards the first node; maintaining the other pool proxy in a passive state towards the first node; sending a heartbeat signal from the active pool proxy to the passive pool proxy via one or more of the pooled second nodes; and activating the passive proxy towards the first node in the event that the heartbeat signal is not received at the passive proxy. 